Add a new wasm32-wasip3 target to Rust
#147205
Conversation
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Noratrieb These commits modify compiler targets. |
rustbot
added
S-waiting-on-review
rustbot
added
T-compiler
|
I'll also note that this target won't build until rust-lang/libc#4733 is included as well. Additionally, following the guidelines here ... r? compiler_leads |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
There was a problem hiding this comment.
Question (somewhat off-topic): what are the long term plans for the wasm32-wasip* set of targets? Or are the WASIpN more like "profiles" in terms of which WASI APIs are available?
There was a problem hiding this comment.
I wouldn't say that the WASI targets are quite like profiles. For today's meeting between T-Lang and the Wasmtime team (unrelated to this PR), Alex wrote the following about the WASI versions. I thought it was really good, so I'll paste it here in full:
Appendix C: WASI Versions
To expand on the glossary terms above:
- WASIp1 - no longer in development. Completely unrelated to the component model. Completely custom ABI and type system used to define APIs, and most APIs looked more-or-less like a C signature.
- WASIp2 - first release of WASI "rebased" on the Component Model. All APIs defined in terms of WIT using component model types (e.g.
record,string, etc). Functionality-wise WASIp2 is a superset of WASIp1 and notably includes support for TCP/UDP sockets. This more-or-less conicided with the first "release" of the component model itself, although the component model doesn't have an official release cadence. In lieu of that WASI versions have been used to introduce component model features. Regardless this is why Rust'swasm32-wasip2target, for example, produces a component instead of a core module as output.- WASIp3 - next in-development version of WASI, not currently released/stamped. Major feature over WASIp2 is native async support in the component model itself, reflected in WIT as
asyncfunctions for example. Additionally there are two new types in WIT,future<T>andstream<T>. Functionality remains the same as WASIp2 except that doing async operations is "much nicer" in terms of how languages integrate. Semantically it's now possible to invoke concurrent computations within a single component if it's exported as anasyncfunction in WIT.Notably WASIp1 is incompatible with WASIp{2,3} due to how its APIs are defined. The core-level ABI and types of WASIp1 are incompatible with the component model and WASIp{2,3}. For WASIp{2,3}, however, the underyling format is "just a component" which means that a component can simultaneously import, and export WASIp2 and WASIp3 APIs. This means that all development of WASIp3-as-a-standard has been using the
wasm32-wasip2Rust target, for example. WASIp3 does not mean that WASIp2 is gone and inaccessible, but rather WASIp3 means that there's access to more functions. Idiomatically a true WASIp3 target wouldn't use WASIp2 at all, and that's the end goal, but this is not a requirement in the transition period from WASIp2 to WASIp3.
The plan is to eventually drive WASI to a 1.0 status, at which point we'll be able to drop the "preview" suffix. From a maintenance perspective WASIp2, WASIp3, and the eventual WASI 1.0 will share most of their infrastructure in the compiler, with most of the differences being in the stdlib. This should make them relatively easy to maintain as a set. This is different for WASI 0.1, which is different enough from the other targets that it needs to be maintained as its own target.
There was a problem hiding this comment.
Okay, that makes sense and is helpful context. Thanks.
This commit adds a new tier 3 target to rustc,
wasm32-wasip3. This follows in the footsteps of the previouswasm32-wasip2target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the
wasm32-wasip3target looks exactly the same aswasm32-wasip2except thattarget_env = "p3"is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as thewasip3crate. Over time this target will evolve as implementation in guest toolchains progress, notably:wasi-libcwill be updated to use WASIp3 natively which Rust will then transitively use.std::thread, for example, on this target.These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.